feat(storage): migrate storage APIs to AmplifyContext - #14874

Reviewed the AmplifyContext migration. The mechanical rename hunks are compiler-guarded so I focused on the two runtime seams (resolveCtxArgs back-compat and the resolveServerContext bridge) and the semi-public /internals surface. Strong PR overall — the server-bridge bug (a20993a) is exactly the one worth catching, and the guarding test genuinely exercises it. A few notes below, mostly nits plus one coordination question on the /internals signature break. Nothing blocking for a feature branch.

Careful, correctly-scoped migration that clears the bar that matters. I traced it end-to-end and verified the one thing that would silently break the server path — no call site still reaches the global singleton. Nothing blocking; findings below are mostly cleanups the diff surfaced, plus one error-surface change worth confirming.

What I verified

Migration completeness (the thing that kills a migration like this). A single missed call site — one worker still reaching Amplify.getConfig() / Amplify.Auth — compiles fine, passes most tests, and then silently uses the global config on the isolated server path (a cross-request credential leak in the worst case). So I enumerated all 154 storage src/*.ts files on the head branch and grepped for surviving global usage. The only hits are ctx.fetchAuthSession() / amplify.fetchAuthSession() (the correct threaded calls) and one comment. Zero global leakage. For a 64-file singleton removal, that's the result you want.

The server bridge is correct and complete. Checked resolveServerContext against the actual AmplifyContext interface: it supplies all five members (resourcesConfig getter, libraryOptions, fetchAuthSession, clearCredentials, getTokens) — no missing method that would throw at runtime. The fetchAuthSession: options => …(options ?? {}) default is right (context options optional, AuthClass's required); getTokens correctly omits the default. The test is genuinely adversarial — it mocks a method-less AmplifyClass, exactly the object a plain cast blows up on, and asserts the branded branch doesn't consult getAmplifyServerContext. That's the right way to test a bridge: reproduce the runtime shape the type system hides.

The disclosure that landed auth #14836 has the same latent server-path bug (getCurrentUser → ctx.getTokens on a method-less class) is exactly the note to surface. Endorse the follow-up — a shared core-level server bridge is the correct end state so each category doesn't re-implement this.

1. Unconfigured-path error surface changes (inherited from core, but Storage now exposes it)

Pre-migration, uploadData({path}) before Amplify.configure() flowed into resolveS3ConfigAndInput, where getConfig()?.Storage?.S3 ?? {} yielded no bucket → a StorageValidationErrorCode (NoBucket). Post-migration, resolveCtxArgs calls getGlobalContext(), which now throws 'No AmplifyContext available…' before any Storage validation runs. So a misconfigured/too-early call surfaces a different error name and message than on v6.

This originates in core (landed with auth), not this PR — but Storage's public APIs now inherit it, and anyone catching the old validation code on the unconfigured path sees a change. Worth a one-line acknowledgment that the pre-configure() error surface shifts, and confirmation that's intended for v7. Not blocking — it's a strictly clearer error, just a different one.

2. remove server wrapper: collapse the redundant if/else

In server/remove.ts both branches are now byte-identical:

if ('key' in input) {
  return removeInternal(ctx, input);
} else {
  return removeInternal(ctx, input);
}

Pre-existing (each branch previously inlined getAmplifyServerContext(contextSpec).amplify), but since the PR rewrote exactly these lines, the dead discrimination should collapse to a single return removeInternal(ctx, input);. Cosmetic.

3. JSDoc description drift on the server @param

Across the server wrappers the param was renamed contextSpec → ctxOrContextSpec, but the description still reads "The isolated server context." It's now either an isolated server context or a direct AmplifyContext — the whole point of resolveServerContext. Update the description text (e.g. "The isolated server context, or a resolved AmplifyContext."), not just the name. Trivial.

4. (...args: any[]) impl erases internal type-checking (accepted tradeoff, worth naming)

The any[] impl means TS can't verify the body against the overloads — if resolveCtxArgs's returned tuple ever drifted from what the impl destructures, the compiler wouldn't catch it. This is the established auth-#14836 pattern and the mitigations are real (public overloads constrain callers; resolveCtxArgs<[Input]> is generically typed; tests exercise both arities). I'd accept it — flagging only that the safety net moved from the compiler onto resolveCtxArgs being correct, which is why core's resolveCtxArgs.test.ts matters as much as any test here.

Scope calls I agree with

• Endpoint-provider feature and server-impl deletion are correctly deferred (depend on unlanded core Storage/types.ts + adapter-nextjs split).
• Required ctx (no global fallback) on internals/apis/* is the right call given first-party consumers migrate in lockstep on this branch.